Certain functional requirements need to be met in order to implement a scalable energy-aware networking 
system. While Chapter~\ref{sec:perfsonar} exploers whether perfSONAR-PS is a suitable entity for serving 
the role of data dissemination within such a system, this chapter examines more closely what are the underlying functional
requirements of the system as a whole by using perfSONAR-NC Measurement Archives as a testbed. 


\section{Blueprint of energy-aware networking}

By assuming that a data dissemination model is in place, attention can be given to remaining underlying components 
of an energy-aware networking solution. Notably, the core of such a system is the capability of putting different 
types of metrics in context of one another so that an energy profile can be created for a network node. As discussed 
in Chapter~\ref{sec:metrics} this can be achieve through a formula the input of which is based on:
 
\begin{itemize}
	\item per-port utilization readings of a node, and
	\item node energy consumption readings
\end{itemize}

Various data sources exist for these metrics. Although port utilization is usually monitored by requesting readings 
from the network node itself, it is more common to have a PDU as the data source of energy readings although a limited
number of network devices offer the tracking of such values via their command line. Moreover, establishing communication with the data sources
can be done through different, locally-regulated methodologies. A scalable solution to this is therefore to abstract the operations of accessing, reading 
and storing data from location-specific data sources into routines separate from the data dissemination system. Therefore, in Figure~\ref{fig:trafficflow} the two metrics
are depicted as RRD and SNMP entities. 

\begin{figure}[h]
	\begin{center}
			\includegraphics[width=5.0in]{../presentation/images/trafficflow.png} 
	\end{center}
	\caption{GreenSONAR test system}
	\label{fig:trafficflow}
\end{figure}
\vskip2em

The next  component of the system is the Measurement Archive which can be expressed as the combination of the "gather script" and "MAIN-DB" components from the aforementioned figure. An important design consideration for this component is whether it computes the energy weight of local devices itself and then servers a tuple of device network identifiers and energy weights or whether it provides such needed data to clients to do the computation instead. The former approach however would obscure certain parts of the data by performing aggregation. 
\\
The dotted vertical line in the figure is meant to delineate two different administrative domain. The arrow inbetween the "MAIN-DB" and "query-script" components can be perceived as Services Layer provided by perfSONAR NMSOA framework. A client requesting the data can then be used for modifying the routing or forwarding logic of network nodes part of a remote domain. Such a client is constructed by extending perfSONAR's query classes. Various technologies can aid the process of modifying network operations with regards to the networking features supported by local devices:

\begin{itemize}
	\item SNMP set queries - SNMP queries can be used to modify forwarding logic by the modification of VLANs a switchport is assigned to via the Q-BRIDGE-MIB information base.
          Also, SNMP queries can be used to modify the routing logic of network devices both in terms of static and dynamically-learned routes
    \item OpenFlow - As the OpenFlow protocol makes a great deal of distinction inbetween the routing/forwarding plane and the data plane such features are already built into the protocol 
    \item OGF NSI-CS- For devices supporting the Open Grid Forum (OGF) Network Service Interface Connection Service (NSI-CS) standardized APIs can be used for performing such modifications
\end{itemize}



\section{Test setup}
In order to test what difficulties might arise with the underlying functional requirements of the system, a test model was created. The model takes into account the infrastructure present in the DAS-4 environment at the University of Amsterdam such as PDU energy readings that are stored in RRD archives, however the underlying data sources and how they are accessed is a design consideration rather than a
restriction. The setup defines the following components:

\begin{itemize}
	\item Measurement Archives for distributing RRD and SNMP data (Appendix~\ref{app:ma_extension})
	\item A BASH script for gathering interface statistics of local devices and
	calculating the percentage utilization of their ports (Appendix~\ref{app:ma_extension})
\end{itemize}

The two types of measurements served are linked together by using the Network Layer address of nodes. A client of the system, which knows in advance the network location of other participants, can establish
the information offered by another participant by issuing a query that shows what archives exist at their location. A response of such a query takes the following form:


\begin{lstlisting}[basicstyle=\scriptsize]
...
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
 <data xmlns:default="http://stager.uninett.no/perfsonarnc/1.0">
  <default:name xmlns="http://stager.uninett.no/psnc/1.0">145.100.102.114_snmp</default:name>
  <default:name xmlns="http://stager.uninett.no/psnc/1.0">145.100.102.114_pdu</default:name>
  <default:name xmlns="http://stager.uninett.no/psnc/1.0">145.100.102.115_snmp</default:name>
  <default:name xmlns="http://stager.uninett.no/psnc/1.0">145.100.102.115_pdu</default:name>
  </data>
</rpc-reply>
...
\end{lstlisting}

By determining the types of archives available at a remote location, a locally-running client script can request the ones that represent devices used by the routing tables of the local routing infrastructure. The SNMP archive is implemented as a flat file. Entries part of the file take the following form:
\vskip1em
\small{\emph{Timestamp: UpInterfaceCount/TotalInterfaceCount, IF1=\%Utilizatoin, IF2=\%Utilizatoin, ...}}
\vskip1em
\normalsize
The PDU Measurement archive provides the average of the latest entries appended to a Round-Robin database that describes the energy readings of the respective nodes.

